As computers and computing devices have become a prevalent part of modern life, the ability to produce appropriate software for these devices has increased in importance. In order to economically produce quality software in a timely fashion, it is often desirable to measure and evaluate the productivity or efficiency of individuals/teams who are responsible for drafting or otherwise controlling the generation of software (hereinafter collectively referred to as “developers”). For example, software that is especially defective may require extensive effort and time to reach production in final form, whereas software that is relatively error free may be marketed with confidence in less time using less effort. In general, inefficient or unproductive developers can cost companies a significant amount of resources due to excess development costs, lost market opportunities, and so forth. Additionally, the instability introduced into the code as a result of rework on the code contributes to reducing the quality of the product.
In other industries, it has long been common to evaluate employee performance by evaluating the quality of the employee's product. For example, an autoworker's skills can be evaluated by examining the quality or performance of a completed automobile, and a chef's proficiency in the kitchen can be judged by the taste and presentation of a meal. However, the software industry presents unique challenges in this regard.
In order to provide accountability for poor developers and rewards for proficient developers, as well as to adjust critical processes, the software industry has long sought an effective measure by which to judge developer skill and performance. A number of such measures have been implemented in the past, however, each such measure has had drawbacks that have prevented widespread adoption and industry satisfaction. For example, one such system involves using the number of bugs found in code, often phrased as bugs per thousand lines of code, or bugs per KLOC, to measure the productivity of the developer. This measure has met with great resistance from developers for a number of reasons. Primary among its drawbacks is the general inability to easily and accurately distinguish bugs that required extensive revision from bugs that could be simply and quickly fixed. For example, some bugs require only that one character be changed, whereas others require many thousands of code lines to be changed. Treating all bugs the same thus introduces significant inaccuracy into the productivity measurement process. Moreover, developers often feel that using bug counting as a productivity measure unfairly favors developers working on simple problems to the detriment of those working on more complex issues. While managers and others who oversee large numbers of developers may feel that the laws of large numbers result in overall statistical accuracy of this measure, that does not operate to alleviate the unfairness of the measure as applied to individuals. Moreover, for those developers so inclined, the bug counting measure is fairly easy to “game” or manipulate in the developer's favor.
Other means of measuring developer productivity have been implemented as well to some extent in the industry. However, none has attained a level of fairness and accuracy sufficient to develop widespread developer support and endorsement. If a particular system for measuring coding productivity does not meet with relatively wide spread developer support, then it will be difficult to use such a system to drive improved productivity. Accordingly, a system and method for accurately and fairly measuring developer productivity is needed.